I don't think any of these should be exposed. There all about key/app updates and don't function in useful ways. Maybe update coordinators could be exposed but I'd prefer the first two weren't

I agree on principle; the issue is that they're already exposed in the concrete implementation AdminWebsocket and I'm trying to stub out documentation for their request/response payloads (just linking to the rustdoc) but can't reference the interface methods like I've done for all the other request/response payloads. Perhaps it's wasted work, but it only takes me a couple minutes per method and then it's done.

Those calls are experimental, but I think it's okay to expose them, because we didn't retract the countersigning calls either, for example.

What I don't understand is in which way is this blocking you, @pdaoust? You're saying you're linking from JS to Rust docs. If these methods don't exist on the JS API, then there's nothing to link from. What is the problem there?

@jost-s they do exist on the AdminWebsocket concrete implementation (and I presume they're functional); it's just that they didn't get back-added to the AdminApi interface. In all my documentation stubs for input/output payloads, I reference the API endpoint they belong to by pointing to the interface method, not the method on any given implementation (of which there's only one, but whatever). (Happy to be told that's a silly place to point to too.)

@pdaoust Ah, okay. I suggest not linking from the payloads to API calls. Some payloads are used in multiple places, and an API doc page like this gives an excellent overview over which call uses which payload https://github.com/holochain/holochain-client-js/blob/main/docs/client.adminwebsocket.md

It'll be even easier to see for each call once we refactor the JS client to use less indirections like the requester.

hm, maybe this is another case of me thinking about things too rigorously and not considering that people's mode of discovering these input/output payloads will 90% be via the interface's list of methods.

Glad to hear the Requester<_, _> thing is going away.

It does bother me that the AdminApi interface isn't documented at all, and the AdminWebsocket gets all the documentation. I want to look into that.

But anyhow @jost-s regarding the subject of the PR, does it look okay and merge-worthy? Feels like a "why not; it's just a few lines"

As it's not blocking you, @pdaoust, I'd follow @ThetaSinner's request to only expose the update coordinators call.